DBハンズオンセミナーでオンプレからAWSへのデータベース移行を学んできた
はじめに
こんにちは。大阪オフィスの林です。
2019年9月4日（水）に赤坂インターシティコンファレンスで開催されたDBハンズオンセミナー (Transformation Day Tokyo 併設) に参加してきました。ハンズオン冒頭のデータベース移行に関する説明が体系的で分かりやすく移行のイメージがし易かったので、簡単ですが内容を紹介したいと思います。
本記事は、以下の構成からなります。
- データベース移行のパターン
- データベース移行のステップとポイント
- AWSから提供されているデータベース移行ツール/サービス
- まとめ・感想
データベース移行のパターン
オンプレミスからのデータベース移行パターンは大きく4つに分類されるとされています。 1. Re-Host 2. Re-Platform 3. Re-Platform & Re-Architecture 4. 組み合わせ（段階的移行）
- Re-Host
- Re-Platform
- Re-Platform & Re-Architecture
- 組み合わせ（段階的移行）
既存のデータベース環境を出来るだけ変更せずにクラウド化する、いわゆる「Re-Host」のパターンです。 オンプレ環境の場合、オンプレのサーバ上にデータベースエンジンを入れてるシステムが大多数であると思います。そのシステムを丸ごとクラウド化するような移行パターンです。 AWSの場合、例えばEC2でサーバを構築し、その中にデータベースエンジンをユーザーでインストールすることで、オンプレのときとほぼ同じ環境をクラウド環境に展開することが出来ます。 何が何でもRDSを使わなくても良いので、まずは安全にシンプルにクラウドへ移行する方法を採用するもの一種の手です。
既存データベース環境からクラウドのマネージドサービスに移行しクラウド化する、いわゆる「Re-Pratform」のパターンです。 マネージドサービスを使うのでクラウドの恩恵を受けやすくなるという点がメリットではあるものの、マネージドサービスを使うとユーザーの手の届く範囲が限られるため、移行後の設定がどこまで出来るのか？どうやってやるのか？すぐできる？などをしっかりと事前に調査したうえで移行を行う必要があります。
既存データベース環境のRe-Platformと併せてRe-Architectureも行うパターンです。 変更が多いですが移行が1回で終わるメリットがあります。移行の影響や作業時の影響などをしっかりと見定められていれば採用してもよい移行方法と言えます。
兎にも角にもまずはシンプルにRe-Hostでクラウド化し、次回以降のステップでより最適なプラットフォームやアーキテクチャに変更するパターンです。 将来的にはより最適なプラットフォームやアーキテクチャへ移行するのですが、まずはシステムのクラウド化を優先するようなケースが該当します。移行作業が複数回発生するため、その回数分データベースの停止時間も増えます。ただ、一度の移行ですべて一気にやるのは高いリスクを伴う場合もあるので、段階的に最適化を図っていくのが現実的だろうと私自身は考えています。
データベース移行のステップとポイント
移行のパターンが決まれば（もしくは移行パターンの検討と併せて）、次に移行のステップとポイントを整理します。 移行のステップはおおきく2つあり、「データベースの製品固有のツールを使う」か「AWSから提供されているツールを使う」かです。どちらを選択するかは制約や条件によって様々ですが以下の記載を参考にして頂ければ幸いです。
それでは下図を見ながらどの移行ステップを踏むほうがよいか、順を追って説明していきます。 まず初めにデータ量だったりシステムの制約を調査し、移行に十分な停止時間を取れるかどうかを確認します。 移行に十分な停止時間が取れ、且つデータベースのエンジンも同じ場合は、データベース標準のダンプやバックアップを取得して移行します。この移行が最もシンプルで簡単な移行の方法です。 次に、十分な停止時間が取れるが、データベースのエンジンが変わる場合です。こちらはデータベースのエンジンよって変わってくる部分でもありますし、実際にやる場合には十分な検証が必要になるでしょう。 次に、移行に十分な停止時間が確保できない場合でデータベースのエンジンが同じ場合です。この場合はデータベース製品固有のレプリケーションを使うとよいでしょう。ただし、レプリケーションはライセンスの問題なども絡んでくるため、製品純正のレプリケーションが組めるかと同時にライセンス違反をしていないかも併せて確認する必要があります。またオンプレとAWSを接続する口も必要になるので事前に確認しましょう。 移行に十分な停止時間が確保できない場合で、データベースのエンジンも変わる場合、この場合はAWSから提供されているサービス「DatabaseMigrationService（DMS）」を使って移行します。
ちなみに、ダンプファイル（バックアップファイル）やCSVファイルを使って移行する場合でRDSを使う場合はOSレイヤには入れないので、AWSから公開されているこちらを参照し、実際の方法を確認いただければと思います。
AWSから提供されているデータベース移行ツール/サービス
AWSから提供されているデータベースの移行ツール/サービスは2種類あります。
- Schema Conversion Tool(SCT)
- Data Migration Service(DMS)
- Schema Conversion Tool(SCT)
- Data Migration Service(DMS)
SCTはアセスメントとスキーマの変換をやってくれるツールです。アセスメントではスキーマ変換の難易度を4段階でレポートしてくれるので、SCTのレポートを見て手動での移行が必要と評価された部分は「Database Migration Playbook」を見て対応するワークアラウンドがあるかどうかを確認します。 <参考> https://aws.amazon.com/jp/blogs/news/the-database-migration-playbook-has-landed https://aws.amazon.com/jp/dms/resources/
DMSはデータベースのデータを移行するサービスで、データベースのスキーマやテーブルが出来上がっている状態で中身を移行させるサービスです。※スキーマの変換をさせる訳ではありません。 DMSではロジカルレプリケーションを使っているとのことなので、移行元のデータベースのトランザクションログをSQLに変えて移行先のデータベースに流します。それがゆえに非同期処理となり、移行元と移行先のデータの整合性にラグがある発生する場合があります。最終的な移行（ファイナライズ）のタイミングでは完全にデータが同期されたことを確認するという点も忘れずに実施する必要があります。
- 初期ロード（Fullload）
- データ更新（CDC、差分）※定期実行
- アプリケーション停止
- 最終差分データ更新（CDC）
- アプリケーション再開（必要に応じて向き先変更）
DMSを使ったデータ移行の流れ
※データベースだけでいうと3～5がダウンタイムになる。
DMSはAWS側のNWにインスタンスが立つので、AWS側からオンプレミス側に接続出来るような構成を取ることが必須となります。DMSを使う場合は、この接続口／構成が取れる環境を作れるかどうかも事前に確認しておく必要があります。
まとめ・感想
ハンズオンには初めて参加したのですが、単純に手を動かすことだけにフォーカスしていなく、冒頭に体系的な説明があったので個人的にはすごく勉強にもなりました。 オンプレからAWSへのデータベース移行は本記事に記載した制約や条件にピッタリハマる要件ばかりではないと思いますので、「〇〇の時には××を優先する」とか「□□の時には△△は諦める」などある程度自分なりの指針をもって検討を進めたいと思います。
以上です。実際のハンズオンの内容も別途まとめたいと思います。
